Fold a processor identity into the workflow cache key — Closes #109 - #110

The class-name default keeps processors that declare nothing apart, but
it cannot catch the case that actually matters: two distinct classes
pinning the same explicit processor_id, as a new processor copy-pasting
a shipped identity would. Cache keys are scoped by that identity, so the
two would read back each other's artifacts as cache hits.

Rejecting at wiring time makes the property an enforced invariant rather
than a convention every new processor has to remember, and fails in CI
instead of at API startup. The guard keys on the identity alone, so two
processors claiming one format remain legal and order-resolved — the
documented first-registration-wins contract is unchanged.

Folding a processor identity into the cache key invalidates every
existing artifact by construction — the API derives the five-segment
shape and never probes the old one — so the entries are unreachable
storage cost until swept. The sweep also clears the orphaned .bedpe and
bigInteract index artifacts stranded when those formats were re-typed;
they are retired-scheme keys too, so they need no separate pass.

Both backends are covered because a deployment runs one or the other,
and cfdb purge-legacy-cache exposes them through the installed console
script so the sweep can run from a deployed image. It is a dry run
unless --apply is passed, and it refuses to act when both an S3 bucket
and a local root resolve rather than guessing which cache was meant —
WORKFLOW_S3_BUCKET in the environment is enough to reach that state
alongside an explicit --local-root, and purging the wrong store cannot
be undone.

Two failure modes are surfaced rather than absorbed. DeleteObjects
reports per-key failures in the response body instead of raising, so a
sweep that deleted nothing for want of an s3:DeleteObject grant would
otherwise report success; and a response confirming fewer keys than were
requested means something was neither deleted nor complained about. Both
raise, and the sweep is idempotent, so re-running after fixing the cause
picks up whatever is left.

The local sweep prunes only the directories its own deletions emptied.
The root is operator-supplied, so an unrelated empty directory under it
is not the sweep's to reclaim.

Pins the property the issue asks to enforce: two processors claiming the
same file and artifact kind at equal processor_version derive different
keys. Covered as an example at both the keys and the Processor layer, as
a Hypothesis property over the whole input domain, and against the
shipped TabixIntervalProcessor and BamIndexProcessor pair the issue names
as staying apart only by accident.

is_legacy_cache_key gets the heaviest coverage, because it decides what
an irreversible sweep deletes. Two properties bracket it: no key
cache_key can mint is ever claimed, so a live artifact cannot be swept;
and every key the retired scheme could mint is claimed, so the migration
leaves no orphan. Around them sit the rejection cases — wrong segment
counts, blank segments, foreign objects sharing the bucket, a
workflow_key, and a current key stripped of its leading segment as an
over-specified purge prefix produces.

The shipped processor identities are asserted as literals rather than
derived from the classes. They are wire constants: every cached artifact
is keyed under one, the README documents "tabix-interval" inside an
example key, and changing a string silently invalidates that processor's
whole cached corpus. Deriving them would assert nothing.

The duplicate-registration test previously registered one class twice,
which the class-name default makes nearly unreachable. It now uses two
distinct classes pinning one identity, and asserts the message names the
identity and the incumbent, since that message is the operator's only
diagnostic. The ordering test needed a second BAM-claiming class for the
same reason, so it now also documents that the guard is scoped by
identity rather than by format.

cfdb.cli had no test module at all, and this change adds a command to it
that deletes production data irrecoverably. Both usage guards are now
covered — the no-target case and the ambiguous case where an S3 bucket
and a local root both resolve — and the ambiguity test asserts that
neither sweep ran, not merely that the message was printed.

An autouse fixture clears the five environment variables the options
bind to. Every one of them leaks from a developer's shell, and without
the fixture the ambiguity guard would fire on tests that never mention
S3, passing in CI and failing locally.

The sweep's boundaries get direct coverage: pagination across more than
one listing page, the delete-request batch boundary, prefixes written
bare or slashed, and a neighbouring environment whose prefix is a strict
textual prefix of the swept one. The over-specified prefix is a
regression test — it deletes a live artifact without the artifact-kind
check in is_legacy_cache_key.

The DeleteObjects error path uses a client double rather than moto,
which populates Errors only for versioned deletes the sweep never
issues. purge_s3 takes its client as a public parameter, so the double
stays on the public surface.

A Hypothesis property spans the two modules: for any file identity
seeded under both schemes, the sweep deletes exactly the retired entry
and leaves what cache_key mints. That is what catches the deriver and
the sweep drifting apart in a future key change.

The identity property was pinned only at key derivation, never where a
wrong answer would actually be served. The router now has to prove that
an artifact cached under another processor's identity is a miss on GET,
on HEAD, and on the readiness probe, and that an artifact sitting at a
retired-scheme key is likewise unreachable — the latter being what makes
the sweep safe to run and what leaves the shipping deploy cold.

Several cache-hit tests had become tautologies. They rebuilt the expected
key with the same expression cache_key_for evaluates, so they would have
kept passing if the identity segment were dropped entirely. They now seed
through the processor's own derivation, which is the agreement the router
probe and the processor put actually depend on.

Two fixtures held four-segment key literals under a comment claiming they
matched what cache_key produces in production. That stopped being true,
and the executor stub's keys reach real JobRecord.artifact_cache_keys in
integration runs, so both are now derived. The executor also asserts the
persisted keys equal what the processor derives, closing the chain from
producer through job record to router probe.

The end-to-end suites asserted only that a cached path existed, which
holds under any key scheme. They now check the shape a real processor
driven through a real worker actually wrote.

test_lifespan_registry covers a hole the duplicate-identity guard made
consequential: the existing lifespan test replaces default_registry with
a MagicMock, so no test had ever run register against a registry already
holding PassthroughProcessor. It also pins that startup builds a fresh
registry, the one assignment keeping a re-entered lifespan from turning
the guard into a boot crash-loop.

Remaining changes are call-site updates for the new cache_key signature.

…tion

…ecutor

install_jobs_index was a synchronous fixture calling FakeCollection.create_index,
which is a coroutine matching Motor's API. The coroutine was never awaited, so
the partial-unique index on workflow_key was never created and the mutex it
backs was absent for every test that requested the fixture.

The concurrent-dedup assertions in test_concurrency.py have therefore never
exercised the mutex they name. They failed on two distinct job ids and were
absorbed as expected failures by an unrelated known-bug entry, so the gap was
invisible. With the index installed they pass on the real behaviour.

The tabix_macos_sigpipe_under_load entry listed AssertionError in both its
raises tuple and its retryable predicate. It matches on format alone, covering
nine of the eleven formats, so it absorbed every assertion failure in those
scenarios on every platform and reported each as an expected failure caused by
a subprocess SIGPIPE that may not have occurred.

AssertionError is the type every assertion in the suite raises, so this made
the affected tests unable to fail: deleting the processor identity segment from
cache_key produced eight expected failures and exit code 0. Ten genuinely
failing concurrency tests were being reported the same way.

A known-bug entry has to name the failure it actually knows about, so the entry
now matches only the RuntimeError carrying the SIGPIPE signature.